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Abstract : Domain Name System (DNS) is the largest and 
most actively distributed, hierarchical and scalable database 
system which plays an incredibly inevitable role behind the 
functioning of the Internet as we know it today. A DNS 
translates human readable and meaningful domain names 
such as www.iitg.ernet.in into an Internet Protocol (IP) 
address such as 202.141.80.6. It is used for locating a 
resource on the World Wide Web. Without a DNS, the 
Internet services as we know it, would come to a halt. In 
our thesis, we proposed an Intrusion Detection System(IDS) 
for Kaminsky cache poisoning attacks. Our system relies on 
the existing properties of the DNS protocol. 

Keywords — DNS, DNS Cache poisoning, Kaminsky DNS 
Cache poisoning, IDS 

I. Introduction 

Cache poisoning in DNS[i][ii] is where an attacker 
successfully injects bogus data into the recursive 
nameserver's cache, causing it to give a reply containing 
spoofed IP address for a domain to a resolver or client. It is 
similar to "arp spoofing" where an attacker replies with 
another MAC address. 

The Kaminsky DNS[iii] attack is a recently discovered 
vulnerability in the DNS protocol [iv] that allows an attacker 
to effectively poison the DNS cache with little effort, 
compared to the traditional cache poisoningfv] attacks. 
Kaminsky attack is a type of brute force cache poisoning 
attack which allows an attacker to perform continuously with 
forged DNS response for a domain name without the need to 
wait for DNS cache timeouts. Unlike the traditional DNS 
cache poisoning attack the greatest advantage of Kaminsky's 
attack is that if the attack does not succeed at the first trial, 
the attacker can immediately retry, without the need to wait 
for TTL of the cache to expire. This improves the probability 
of success of the attack. 

DNS security system are generally concerned with cache; 
DNS cache is inevitable for performance of the DNS system. 
Kaminsky cache poisoning attack is the main threat to the 
DNS security to which many currently deployed DNS servers 
are vulnerable. So in the paper, we concentrate to devise a 
new technique to cope with the Kaminsky attack. 

II. Material and Methodology 

Several schemes such as the DNSCurve[vi], WSEC[vii] 
DNS, Anax[viii] have been proposed in the literature on 
improving the DNS security against cache poisoning attacks. 



However, they require explicit or implicit changes to the DNS 
protocol and some are limited in providing security. 
Some of the world's top DNS experts decides for a temporary 
fix against the cache poisoning attack - randomizing the source 
port[ix]. In this system attacker must correctly guess the 
unique 16-bit transaction ID along with the 16-bit port number 
as well. The effective transaction space becomes 2 16 x2 16 = 2 32 
number[x]. Here some of the ports(0-1023) number are fix for 
some certain application and cannot be used for other 
purpose[xi]. 

Sometimes Port randomization used in every outgoing query 
becomes ineffective by the presence of devices such as routers, 
gateways or, firewalls or load balancers that perform 
NAT/PAT which may modify the source ports without 
preserving the nature of original port randomness[xii]. 
This section provides the overview of the methodology 
devised for IDS to detect cache poisoning using an existing 
DNS infrastructure. When a DNS query response comes to the 
DNS, the IDS first stores it in the raw DNS data collector. 
Then it verifies the source IP address and the corresponding 
hostname in the response packet to be poisonous or legitimate. 
If the IDS can not verify locally, a resolve request is send to 
another DNS server (preconfigured, restricted). Details of 
verified. hostname-IP(RR) mapping are stored in respective 
tables. Figure- 1 shows the flow control of the whole system. 
Each incoming DNS response packet is given as an input. 
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Detection Model 

The model consists of two part capturing module and 
Analysis module. The capturing module captures all the DNS 
response packets received by the DNS server and stores it. 
The next Analysis module checks the authenticity of the 
collected records. Algorithm- 1 is the used in this work. It 
waits for a DNS response packet, once it receives a response 
packet it checks for spoofing (line 1). We label an IP address 
in the resolving packet for a hostname as spoofed, if at least 
three consecutive response packets are received bearing the 
same question and answer pair having different transaction 
IDs and source ports. Because a 

Algorithm 1: Detection Algorithm for Capturing module 

1 if Three consecutive packet contains same question 8 answer & has different 
ID 8 sonrce.fort. then 

2 ''status is trying to poison" 

3 add (hostname, IP, timestainp) in "blacklist" table 

4 else if answer.wunt = 1 & response is for "A" record then 
add(txnJD,liostname,IP,timestamp) in "hostip" table 
if answer.comt==2 & response is for "CNAME" record then 

add (txn_ID,hostname,ip,timestamp) in %sUf table 
add (txnJD,hostname(CNAME),ip,timestamp) in "hostip" table 

if response packet contains additional record then 

add the answertxnjd,hostnanie,ip,time in "hostip" table 
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"blacklist" table. The line 6, if the data is not present in both 
the "legitimate" and "blacklist" tables then, it send a query to 
a specified and restricted DNS for a name resolution. 
Thereafter, it checks the mappings of 'hostname-IP address' 
in the response packet received from the specified and 
restricted DNS with the 

information available in the "host ip" table. If there is a match 
or the IP address resides in same domain name space then, the 
algorithm labels it as a legitimate one and stores it in the 

Algorithm 2: Detection Algorithm for Analysis module 

1 if 'hostname' is in the "legitimate" table, then 

2 Go t o line 13 

3 if IP' for the corresponding 'hostname' is in the "blacklist" table then 

4 Go to line 13 



HI 
11 
12 



Query to DNS(restricted) for 'hostname' resolution 

if 'IP' in the response packet for the queried 'hostname' is same as in the 

table then 

add(hostname,IP) hi the "legitimate" table 

else if 'IP' belongs to the same domain name space then 
add(hostnamejp) in the "legitimate," table 
else 

add(hostnaiiie.IP) in the "blacklist" table 



13 Delete all entry for the corresponding hostname from "host ip" table 



DNS will never query for a hostname available in its cache, 
till the DNS cache has expired (generally 24 hrs.). If the 
spoofed IP address is labelled as Blacklisted, it is stored in 
the "blacklist" table. In line 4 the module checks whether the 
answer contains an A' record, if so then the module stores the 
transaction ID, hostname and the IP address in the table "host 
ip". If the response 

contains a 'CNAME' record(line 6) then, the module stores 
both the hostname along with the corresponding CNAME 
with the same IP address in the "host ip" table. The module 
also stores all the records (hostname,ip address) available in 
the additional section of the response packets, if present. 

Algorithm-2 periodically checks the "host ip" table. If there 
are records present in the table it retrieves them one at a 
time. The Line 1 Searches for an entry of the 'hostname' in 
the "legitimate" table, if it contains the record. If not, the 
Line 3 searches for the corresponding TP address' in the 



"legitimate" table. Otherwise, the algorithm labels it as 
blacklist and stores it in the "blacklist" table. After the 
labelling is done, line 13, delete all entries for the 
corresponding hostname from the 
"host ip" table. 

III. Results and Tables 



The Kaminsky class DNS cache poisoning attack effect mostly 
open recursive DNS servers. Our aim is to detect all those 
responses that reaches a DNS server containing malicious or 
poisoned records. By malicious records we mean the 
"hostname -IP address" mapping is fake. A DNS server has no 
way to check and verify the "hostname-IP address" mappings. 
Therefore, the Capture and Analysis module should reside in 
the recursive DNS server itself. The system runs in parallel 
with the existing DNS 
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server on the same host. The setup created for the experiment 
consists of four machines - one as an Authoritative DNS 
server, one as a Recursive DNS server, one as a DNS client 
and one as the attacker. We assume that the recursive DNS 
server does not contain any authoritative record. The basic 
block diagram for the (software) implementation of the 
proposed Intrusion Detection System is given in the Figure-2. 
As shown in the figure, in Step 1 [1], the Capturing module 
captures each DNS response packet and (Step [2]) stores it in 
the raw DNS data collector. It also checks for any flooding of 
DNS responses, i.e., someone trying to poison with a 
streaming of packets bearing different transaction ID and 
source port having the same question and answer. If so, then 
make the RR response Blacklisted in Step [3]. In Step [5] and 
Step [6], The Analysis module verifies each entry in the Raw 
data collector, whether it is legitimate or not. If not 
legitimate, it triggers an RR entry to the "BlacklistDB" else 
an entry to the "legitimateDB" table respectively. 
The Capture Module captures all the DNS response packets 
off the wire. It collects only the raw DNS packets without 
any verification. Then it stores it in the Raw Data Collector. 
The Capture Module does not collect any information about 
the request packets, as it is not necessary for detection. Since, 
the DNS implicitly discards all the response packets if and 
only if it does not contain the same question with the same 
transaction ID and source port. There are different events that 
may arise during the detection. 

i) When there is no intervention of any third party, i.e., 
Normal operation. A DNS response packet has shown, where 
DNS response for the 'A' record in the answer field for the 
host "www.iitg.ernet.in" is 202.141.80.6, Which is 
legitimate. 

ii) If there is changing of the 'A' or 'CNAME' record in the 
response field. 



A spoof/poison DNS response in Wireshark[xiii] has shown 
in the Figure-3. Here the incoming response packet for 'A' 
record for domain name "www.iitg.ernet.in" has been sent 
with fake hostname-IP address mapping in the answer field. If 
the attacker successfully guess the transaction ID and source 
port number. Then all the client is redirected to the host 
'172.16.100.100', which is not the right one. Here the user or 
DNS has no way to check the mapping. 

iii) If there is changing of the mapping of the 'NS' record in 
the additional field. In the figure-4 a poisoned DNS response 
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has shown, in which the attacker response behave like a 
normal one, where the answer field contains the legitimate 
hostname-IP address mapping, but these time he inject fake 
answer for the 'NS' record. If he success, he can hijack the 
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whole .iitg.ernet.in domain. Any query for any host in the 
.iitg.ernet.in domain will goes to his machines 
(172.16.26.197, 10.12.13.16). Now he can send any mapping 
for any host in that domain. 

iv) When there is continuous response with the same question 
and answer field with different transaction ID and source 
port. This means an attacker generating response packet 
trying to inject his malicious machine address on be half of 
legitimate. 

The Figure 5 shows a snapshot of the "host ip" table in the 
DNS server. The table contains an instance of all the received 
DNS respones packet by the DNS server. The Capturing 
module populates the table with the respective field. 



The Figure-7 displays a snapshot of the "blacklist" table in the 
DNS server. The table contains all the 'hostname-IP' address 
which mapping is not legitimate or fake. After verification the 
Analysis module populates this table. 
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Figure-5 

The Figur-6 shows a snapshot of the "legitimate" table in the 
DNS server. The table contains the record which has been 
verified and labeled as legitimate. The Analysis module 
populate this table after verification. In verification phase, the 
Analysis module also use this table for further verification or 
detection. If some "hostname-IP" mapping is in this table, 
then it can directly confirm its status. 
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"Thereafter the analysis module use this table for further 
Verification of DNS response record. 

fV. Conclusion 

We have witnessed that the Kaminsky DNS cache poisoning is 
k threat to the Recursive Domain Name System, at the same 
fime there are no security measures currently in place to cope 
with this type of attack. Also, the DNS SEC deployment 
Requires a good understanding of managing cryptography, key 

management and coordination across various DNS 

ii 

administrative domains. These are non-trivial issues to 
Overcome and will take time before DNS SEC is fully deployed 
bn the Internet. Therefore, we have proposed an independent, 
pcally deployable IDS for detecting traditional DNS cache 
poisoning attacks along with the Kaminsky DNS cache 
poisoning attack. Our approach does not require any changes 
to the existing Domain Name System and relies on the 
fundamental infrastructure of the Domain Name System. 
Moreover, it works in a fully automated manner. The proposed 
IDS was deployed in a LAN environment and the result 
showed successful detection of DNS cache poisoning attacks. 
Also, the experimental results illustrated the fact that, extra 
DNS request packets are generated due to the step involving 
verification of the DNS response records in our 
implementation. In this scheme, we only label the records and 
store it in the respective databases. We assume remedial action 
against the attacker will be handled by the DNS administrator. 
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